Business entities require business software for performing an array of essential tasks, such as communication, planning, inventory control, order processing, systems monitoring, and nearly every facet of a business' operations. A business entity often requires a software solution with features, interfaces, data management, and other aspects unique to that one specific company. Yet, core functions may be similar among the different unique solutions. These core functions may be provided to several, unique business entities, e.g., companies. In addition to needing to vary several initial deployments among a variety of customer-companies, these varied implementations may need constant updating, to evolve with the evolving business' needs.
Software developers may design and provide a set of software tools in a generic or universal form. These tools may be controlled by a set of customization data that is specific to each unique customer. Unlike the companies' transactional data, which may include millions of data records or more, the configuration and customization data may represent a very small and rarely changing set of data. This data may modify, instantiate, activate, or otherwise implement the provided tools, in a customer specific manner. With the configuration data, customers may be able to modify every aspect of their software experience, including defining the user interfaces, what functions are available on the interfaces, and/or what fields are provided to the user.
To help maintain these software packages, SAP® AG (a developer) introduced an enhancement package strategy as a means to simplify the way customers manage and deploy new software functionality. Customers may selectively implement these software innovations from a developer and activate the software upon business demand. As a result, customers can isolate the impact of software updates from introducing/rolling out new functionality and bring new functionality online faster through shortened testing cycles. Customers no longer have to plan for major releases every few years. They may now choose to selectively implement the business functions or technical improvements that add the value that matters most to their business. A developer may use enhancement packages to quickly and easily deliver business and industry-specific functionality, enterprise services, and other functions that help improve and simplify the use of software through user interface and other end-to-end process improvements.
These enhancement packages may be cumulative from a functional perspective, e.g., current enhancement packages may contain the entire content of earlier packages. So each enhancement package may be based on the previous one. Enhancement packages may also have the same maintenance duration as the underlying core application. Each enhancement package may contain new versions of existing software components. With the enhancement packages customers can choose which software components are updated in their systems, depending on the new/extended functionality they want to use. This may mean that over time the enhancement packages may become bigger and bigger and in the meantime may not be much smaller than a full standard release. At least for customers who do not install the enhancement packages regularly, the intended flexibility and the ease of installation may no longer be given in their full extent.
Example embodiments of the present invention further encourage customer adoption of the enhancement package model and provides unique niche enhancement packages by providing a highly integrated Modular Business Application (“MBA”). Modular Business Applications may be delivered as an add-on for software versions that are already released and delivered to customers. Such released product versions might not be easily extended, since an add-on may have to properly work with the interfaces available in the released versions. Typically, these released versions have a certain set of interfaces that may be used by customers to provide extensions. However, to build whole applications on top of a released version, these interfaces may not be complete enough from a functional point of view. For Modular Business Applications (which should be highly integrated to the underlying product) this means that internal functions/internal development objects of the underlying product that are not part of the official interface—have to be used to get a tight (i.e. highly tailored) integration.
However, calling internal functions may contain a high risk. Since the owners of internal functions are generally not aware of external usages (e.g., by Modular Business Applications) they consider only the internal usages when they change, extend, or correct their functions. From a MBA point of view these internal functions are unstable as they might be changed in an unpredictable way. These changes might be incompatible for Modular Business Applications and could lead to broken business processes or even inconsistent data in the Modular Business Application.
Thus there is a need to build add-ons on already shipped releases without modifying them and without restricting the MBA development on using only released interfaces. Development of Modular Business Applications should be able to use internal (e.g., private) elements from the released products. This may be needed to build highly integrated and function rich applications. But it should be ensured that using these internal development objects does not have side effects in lifecycle management events like installing service packs, installing other add-ons, applying corrections, or doing a version upgrade. Example embodiments of the present invention provide the highly integrated Modular Business Application (“MBA”) to address these issues.